fix(akamai): recover fetcher key on reconciled deploy status by adityamisra08 · Pull Request #3193 · adobe/spacecat-api-service

adityamisra08 · 2026-09-03T09:53:39Z

Summary

deploy-status now returns the managed rule's fetcher key when deployed && freshWrite !== false — i.e. only when the key found belongs to THIS deploy, never a stale key inherited from a prior onboarding.
Lets the Akamai onboarding wizard recover the Bot Manager allowlist key after a deploy whose own HTTP response was lost to the CDN timeout, instead of forcing the customer to re-run Deploy (and rotate the key again) just to see a value Akamai already has.
Updated the doc comments on getManagedFetcherKey and deployStatus that previously asserted the key is "never returned" — narrowed to the new, guarded contract.
Updated the 3 existing deployStatus/freshWrite unit tests whose old assertions ("key is never returned") directly contradicted this intended behavior change.

Companion frontend PR: adobe/project-elmo-ui (same branch name fix/akamai-recover-fetcher-key).

Test plan

npx eslint clean on all 3 changed files
npx mocha test/controllers/llmo/llmo-akamai.test.js — 115/115 passing
npm run docs:lint — no new issues (pre-existing warnings only)
tsc type-check (via pre-commit hook) — passing

deploy-status now returns the managed rule's fetcher key, gated on freshWrite !== false so a stale/inherited key from a prior onboarding is never surfaced. Lets the onboarding UI recover the key for Bot Manager allowlisting after a deploy response was lost to the CDN timeout, instead of forcing a re-deploy just to see it again.

codecov · 2026-09-03T09:59:31Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

MysticatBot

Hey @adityamisra08,

⚠ Degraded review - no spec document was found for this change (searched the PR links, the touched repos' docs, the architecture/guidelines docs, and linked Jira). This review covers code-level quality but could not validate the change against an agreed design, so confidence is reduced. Add a spec link (PR template section 4) and re-request review for a full-confidence pass.

Verdict: Request changes - one blocking finding on the API contract for fetcherKey: null.
Complexity: MEDIUM - small diff; API surface.
Changes: Returns the Akamai Bot Manager fetcher key in deploy-status responses when the key belongs to the current deploy, enabling recovery after CDN timeouts (3 files).
Note: CI checks are currently pending.

Must fix before merge

[Important] fetcherKey: null returned when managed rule exists but fetcher-key header is absent - src/controllers/llmo/llmo-akamai.js:922 (details inline)

Non-blocking (2): minor issues and suggestions

nit: getManagedFetcherKey(ruleTree) is called twice on the same immutable tree when baseVersion is supplied; targetKey from the freshWrite comparison already holds the result - src/controllers/llmo/llmo-akamai.js:922
suggestion: add expect(body).to.not.have.property('fetcherKey') to the existing deployed:false test to lock in the new contract - test/controllers/llmo/llmo-akamai.test.js:559

_{Skill: pr-review | Model: us.anthropic.claude-opus-4-6-v1[1m] | Duration: 0m 54s | Cost: $6.66 | Commit: 91cba0fe92d6bcccbc05cdf7de1fe8ede170d1fd
If this code review was useful, please react with 👍. Otherwise, react with 👎.}

Guard the recovered key against null (rule present but the fetcher-key header itself is missing/malformed) so the response omits the field instead of sending fetcherKey: null, which would read as "recovered" to a consumer checking presence. Also hoists the tree read so it's done once instead of twice. Addresses review feedback on #3193.

github-actions · 2026-09-03T10:21:11Z

This PR will trigger a patch release when merged.

adityamisra08 · 2026-09-03T10:21:50Z

All 3 items from the review addressed in f56b267:

Blocking — fetcherKey: null when the rule is present but the header itself is missing/malformed: fixed via the suggested recoveredKey guard (recoveredKey && freshWrite !== false).
Nit — duplicate getManagedFetcherKey(ruleTree) call: fixed by hoisting into recoveredKey, reused for the freshWrite compare.
Nit — lock in deployed:false contract with an explicit assertion: added, plus the same assertion on the deployed:true/no-header case (which is the actual null-guard regression test).

115/115 unit tests passing.

MysticatBot

Hey @adityamisra08,

⚠ Degraded review - no spec document was found for this change (searched the PR links, the touched repos' docs, the architecture/guidelines docs, and linked Jira). This review covers code-level quality but could not validate the change against an agreed design, so confidence is reduced. Add a spec link (PR template section 4) and re-request review for a full-confidence pass.

Verdict: Approve - all prior findings addressed; no new blocking issues.
Complexity: MEDIUM - small diff; API surface.
Changes: Returns the Akamai Bot Manager fetcher key in deploy-status responses when the key belongs to the current deploy, enabling recovery after CDN timeouts (3 files).
Note: CI checks are currently pending.

Non-blocking (2): minor issues and suggestions

suggestion: The no-baseVersion path returns the fetcher key without freshWrite confirmation. The trust model is sound (callers already own the property's EdgeGrid credentials), but the JSDoc claim that the key is "confirmed to belong to THIS deploy" is slightly imprecise for this case - consider a brief note in the comment acknowledging the trust assumption - src/controllers/llmo/llmo-akamai.js:928
suggestion: Verify that the response's Cache-Control header (or Fastly's Surrogate-Control) prevents caching of this route, since deploy-status now carries a secret value

Previously flagged, now resolved

fetcherKey: null leak when managed rule exists but fetcher-key header is absent - now guarded by recoveredKey && freshWrite !== false
Duplicate getManagedFetcherKey(ruleTree) tree walk - hoisted into recoveredKey and reused for both the freshWrite compare and the response
Missing negative assertions on deployed:false and deployed:true/no-header tests - added, plus positive assertions on the recovery paths

_{Skill: pr-review | Model: us.anthropic.claude-opus-4-6-v1[1m] | Duration: 2m 14s | Cost: $5.08 | Commit: f56b26754e3a10744f71fdc3cc5aa52157ee8820
If this code review was useful, please react with 👍. Otherwise, react with 👎.}

adityamisra08 requested a review from MysticatBot September 3, 2026 09:54

adityamisra08 temporarily deployed to dev-branches September 3, 2026 10:02 — with GitHub Actions Inactive

MysticatBot requested changes Sep 3, 2026

View reviewed changes

Comment thread src/controllers/llmo/llmo-akamai.js

MysticatBot added ai-reviewed Reviewed by AI complexity:medium AI-assessed PR complexity: MEDIUM labels Sep 3, 2026

adityamisra08 requested a review from MysticatBot September 3, 2026 10:22

adityamisra08 temporarily deployed to dev-branches September 3, 2026 10:30 — with GitHub Actions Inactive

MysticatBot approved these changes Sep 3, 2026

View reviewed changes

adityamisra08 temporarily deployed to dev-branches September 3, 2026 11:56 — with GitHub Actions Inactive

Merge branch 'main' into fix/akamai-recover-fetcher-key

a90e9e4

adityamisra08 temporarily deployed to dev-branches September 3, 2026 15:24 — with GitHub Actions Inactive

Merge branch 'main' into fix/akamai-recover-fetcher-key

a3d0a48

adityamisra08 temporarily deployed to dev-branches September 9, 2026 08:59 — with GitHub Actions Inactive

dzehnder mentioned this pull request Sep 9, 2026

feat(serenity): async Semrush-market AI-prompt provisioning (#3194) #3252

Open

Merge branch 'main' into fix/akamai-recover-fetcher-key

f5d861c

adityamisra08 temporarily deployed to dev-branches September 10, 2026 06:14 — with GitHub Actions Inactive

jindaliiita approved these changes Sep 11, 2026

View reviewed changes

Navigation Menu

Uh oh!

fix(akamai): recover fetcher key on reconciled deploy status - #3193

fix(akamai): recover fetcher key on reconciled deploy status#3193
adityamisra08 wants to merge 5 commits into
mainfrom
fix/akamai-recover-fetcher-key

adityamisra08 commented Sep 3, 2026

Uh oh!

codecov Bot commented Sep 3, 2026

Uh oh!

MysticatBot left a comment •

edited

Loading

Uh oh!

Uh oh!

github-actions Bot commented Sep 3, 2026

Uh oh!

adityamisra08 commented Sep 3, 2026

Uh oh!

MysticatBot left a comment •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

adityamisra08 commented Sep 3, 2026

Summary

Test plan

Uh oh!

codecov Bot commented Sep 3, 2026

Codecov Report

Uh oh!

MysticatBot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Must fix before merge

Uh oh!

Uh oh!

github-actions Bot commented Sep 3, 2026

Uh oh!

adityamisra08 commented Sep 3, 2026

Uh oh!

MysticatBot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Previously flagged, now resolved

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

MysticatBot left a comment •

edited

Loading

MysticatBot left a comment •

edited

Loading